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Abstract 


ITU-T Recommendation G.808.3 defines the generic aspects of a Shared Mesh Protection (SMP) 
mechanism, where the difference between SMP and Shared Mesh Restoration (SMR) is also 
identified. ITU-T Recommendation G.873.3 defines the protection switching operation and 
associated protocol for SMP at the Optical Data Unit (ODU) layer. RFC 7412 provides requirements 
for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - 
Transport Profile (MPLS-TP) network. 


This document updates RFCs 4872 and 4873 to provide extensions for Generalized Multi-Protocol 
Label Switching (GMPLS) signaling to support the control of the SMP mechanism. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and howto provide feedback 


on it may be obtained at https://www.rfc-editor.org/info/rfc9270. 
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Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 
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IETF Standards Process, except to format it for publication as an RFC or to translate it into 
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1. Introduction 


RFC 4872 [RFC4872] defines extensions for Resource Reservation Protocol - Traffic Engineering 
(RSVP-TE) to support Shared Mesh Restoration (SMR) mechanisms. SMR can be seen as a 
particular case of preplanned Label Switched Path (LSP) rerouting that reduces the recovery 
resource requirements by allowing multiple protecting LSPs to share common link and node 
resources. The recovery resources for the protecting LSPs are pre-reserved during the 
provisioning phase, and explicit restoration signaling is required to activate (i.e., commit 
resource allocation at the data plane) a specific protecting LSP that was instantiated during the 
provisioning phase. RFC 4873 [RFC4873] details the encoding of the last 32-bit Reserved field of the 
PROTECTION object defined in [RFC4872]. 


ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of a Shared Mesh Protection 
(SMP) mechanism, which are not specific to a particular network technology in terms of 
architecture types, preemption principle, path monitoring methods, etc. ITU-T Recommendation 
G.873.3 [G873.3] defines the protection switching operation and associated protocol for SMP at the 
Optical Data Unit (ODU) layer. RFC 7412 [RFC7412] provides requirements for any mechanism 
that would be used to implement SMP in a Multi-Protocol Label Switching - Transport Profile 
(MPLS-TP) network. 


SMP differs from SMR in the activation/protection switching operation. The former activates a 
protecting LSP via the Automatic Protection Switching (APS) protocol in the data plane when the 
working LSP fails, while the latter does it via control plane signaling. It is therefore necessary to 
distinguish SMP from SMR during provisioning so that each node involved behaves appropriately 
in the recovery phase when activation of a protecting LSP is done. SMP has advantages with 
regard to the recovery speed compared with SMR. 


This document updates [RFC4872] and [RFC4873] to provide extensions for Generalized Multi- 
Protocol Label Switching (GMPLS) signaling to support the control of the SMP mechanism. 
Specifically, it 


e defines a new LSP Protection Type, "Shared Mesh Protection", for the LSP Flags field [RFC4872] 
of the PROTECTION object (see Section 6.1), 
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e updates the definitions of the Notification (N) and Operational (O) fields [RFC4872] of the 
PROTECTION object to take the new SMP type into account (see Section 6.2), and 


e updates the definition of the 16-bit Reserved field [RFC4873] of the PROTECTION object to 
allocate 8 bits to signal the SMP preemption priority (see Section 6.3). 


Only the generic aspects for signaling SMP are addressed by this document. The technology- 
specific aspects are expected to be addressed by other documents. 


RFC 8776 [RFC8776] defines a collection of common YANG data types for Traffic Engineering (TE) 
configuration and state capabilities. It defines several identities for LSP Protection Types. As this 
document introduces a new LSP Protection Type, [RFC8776] is expected to be updated to support 
the SMP mechanism specified in this document. [YANG-TE] defines a YANG data model for the 
provisioning and management of TE tunnels, LSPs, and interfaces. It includes some protection 
and restoration data nodes relevant to this document. Management aspects of the SMP 
mechanism are outside the scope of this document, and they are expected to be addressed by 
other documents. 


2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


In addition, the reader is assumed to be familiar with the terminology used in [RFC4872], RFC 4426 
[RFC4426], and RFC 6372 [RFC6372]. 


3. SMP Definition 


[G808.3] defines the generic aspects of an SMP mechanism. [G873.3] defines the protection 
switching operation and associated protocol for SMP at the ODU layer. [RFC7412] provides 
requirements for any mechanism that would be used to implement SMP in an MPLS-TP network. 


The SMP mechanism is based on precomputed protecting LSPs that are preconfigured into the 
network elements. Preconfiguration here means pre-reserving resources for the protecting LSPs 
without activating a particular protecting LSP (e.g., in circuit networks, the cross-connects in the 
intermediate nodes of the protecting LSP are not preestablished). Preconfiguring but not 
activating protecting LSPs allows link and node resources to be shared by the protecting LSPs of 
multiple working LSPs (which are themselves disjoint and thus unlikely to fail simultaneously). 
Protecting LSPs are activated in response to failures of working LSPs or operator commands by 
means of the APS protocol, which operates in the data plane. The APS protocol messages are 
exchanged along the protecting LSP. SMP is always revertive. 


SMP is very similar to SMR, except that activation in the case of SMR is achieved by control plane 
signaling during the recovery operation, while the same is done for SMP by the APS protocol in 
the data plane. 
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4. Operation of SMP with GMPLS Signaling Extensions 


Consider the network topology shown in Figure 1: 


Figure 1: An Example of an SMP Topology 


The working LSPs [A,B,C,D] and [H.LJ,K] could be protected by the protecting LSPs [A,E,F,G,D] and 
[H,E,F, G,K], respectively. Per RFC 3209 [RFC3209], in order to achieve resource sharing during the 
signaling of these protecting LSPs, they have the same Tunnel Endpoint Address (as part of their 
SESSION object). However, these addresses are not the same in this example. Similar to SMR, this 
document defines a new LSP Protection Type of the secondary LSP as "Shared Mesh Protection" 
(see Section 6.1) to allow resource sharing along nodes E, F, and G. Examples of shared resources 
include the capacity of a link and the cross-connects in a node. In this case, the protecting LSPs 
are not merged (which is useful, since the paths diverge at G), but the resources along E, F, and G 
can be shared. 


When a failure, such as Signal Fail (SF) or Signal Degrade (SD), occurs on one of the working LSPs 
(say, working LSP [A,B,C,D]), the end node (say, node A) that detects the failure initiates the 
protection switching operation. End node A will send a protection switching request APS message 
(for example, SF) to its adjacent (downstream) intermediate node (say, node E) to activate the 
corresponding protecting LSP and will wait for a confirmation message from node E. 


If the protection resource is available, node E will send the confirmation APS message to the end 
node (node A) and forward the switching request APS message to its adjacent (downstream) node 
(say, node F). When the confirmation APS message is received by node A, the cross-connection on 
node A is established. At this time, traffic is bridged to and selected from the protecting LSP at 
node A. After forwarding the switching request APS message, node E will wait for a confirmation 
APS message from node F, which triggers node E to set up the cross-connection for the protecting 
LSP being activated. 


If the protection resource is not available (due to failure or being used by higher-priority 
connections), the switching will not be successful; the intermediate node (node E) MUST send a 
message to notify the end node (node A) (see Section 5.5). If the resource is in use by a lower- 
priority protecting LSP, the lower-priority service will be removed, and the intermediate node will 
then follow the procedure as described for the case when the protection resource is available for 
the higher-priority protecting LSP. 
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If node E fails to allocate the protection resource, it MUST send a message to notify node A (see 
Section 5.5). Then, node A will stop bridging and selecting traffic to/from the protecting LSP and 
proceed with the procedure of removing the protection allocation according to the APS protocol. 


5. GMPLS Signaling Extensions for SMP 


The following subsections detail how LSPs using SMP can be signaled in an interoperable fashion 
using GMPLS RSVP-TE extensions (see RFC 3473 [RFC3473]). This signaling enables: 


(1) the ability to identify a "secondary protecting LSP" (LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from 
Figure 1, here called the "secondary LSP") used to recover another "primary working LSP" 
(LSP [A,B,C,D] or LSP [H,LJ,K] from Figure 1, here called the "protected LSP"), 

(2) the ability to associate the secondary LSP with the protected LSP, 

(3) the capability to include information about the resources used by the protected LSP while 
instantiating the secondary LSP, 

(4 the capability to instantiate several secondary LSPs efficiently during the provisioning 
phase, and 


(5) the capability to support activation of a secondary LSP via the APS protocol in the data 
plane if a failure occurs. 


5.1. Identifiers 


To simplify association operations, both LSPs (ie. the protected LSP and the secondary LSP) 
belong to the same session. Thus, the SESSION object MUST be the same for both LSPs. The LSP ID, 
however, MUST be different to distinguish between the protected LSP and the secondary LSP. 


Anew LSP Protection Type, "Shared Mesh Protection", is defined (see Section 6.1) for the LSP Flags 
field of the PROTECTION object (see [RFC4872]) to set up the two LSPs. This LSP Protection Type 
value is only applicable to bidirectional LSPs as required in [G808.3]. 


5.2. Signaling Primary LSPs 


The PROTECTION object (see [RFC4872]) is included in the Path message during signaling of the 
primary working LSPs, with the LSP Protection Type value set to "Shared Mesh Protection". 


Primary working LSPs are signaled by setting in the PROTECTION object the S bit to 0, the P bit to 
0, and the N bit to 1; and setting in the ASSOCIATION object the Association ID to the associated 
secondary protecting LSP_ID. 


Note: The N bit is set to indicate that the protection switching signaling is done via 
the data plane. 
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5.3. Signaling Secondary LSPs 


The PROTECTION object (see [RFC4872]) is included in the Path message during signaling of the 
secondary protecting LSPs, with the LSP Protection Type value set to "Shared Mesh Protection". 


Secondary protecting LSPs are signaled by setting in the PROTECTION object the S bit, the P bit, 
and the N bit to 1; and setting in the ASSOCIATION object the Association ID to the associated 
primary working LSP ID, which MUST be known before signaling of the secondary LSP. Moreover, 
the Path message used to instantiate the secondary LSP MUST include at least one 
PRIMARY PATH, ROUTE object (see [RFC4872]) that further allows for recovery resource sharing 
at each intermediate node along the secondary path. 


With this setting, the resources for the secondary LSP MUST be pre-reserved but not committed at 
the data plane level, meaning that the internals of the switch need not be established until explicit 
action is taken to activate this LSP. Activation of a secondary LSP and protection switching to the 
activated protecting LSP is done using the APS protocol in the data plane. 


After protection switching completes, the protecting LSP MUST be signaled by setting the S bit to 0 
and the O bit to 1 in the PROTECTION object. At this point, the link and node resources MUST be 
allocated for this LSP, which becomes a primary LSP (ready to carry traffic). The formerly 
working LSP MAY be signaled with the A bit set in the ADMIN STATUS object (see [RFC3473]). 


Support for extra traffic in SMP is left for further study. Therefore, mechanisms to set up LSPs for 
extra traffic are outside the scope of this document. 


5.4. SMP Preemption Priority 


The SMP preemption priority of a protecting LSP is used by the APS protocol to resolve 
competition for shared resources among multiple protecting LSPs and is indicated in the 
Preemption Priority field of the PROTECTION object in the Path message of the protecting LSP. 


The Setup and Holding priorities in the SESSION_ATTRIBUTE object can be used by GMPLS to 
control LSP preemption, but they are not used by the APS to resolve competition among multiple 
protecting LSPs. This avoids the need to define a complex policy for defining Setup and Holding 
priorities when used for both GMPLS control plane LSP preemption and SMP shared resource 
competition resolution. 


When an intermediate node on the protecting LSP receives the Path message, the priority value in 
the Preemption Priority field MUST be stored for that protecting LSP. When resource competition 
among multiple protecting LSPs occurs, the APS protocol will use their priority values to resolve 
this competition. A lower value has a higher priority. 


In SMP a preempted LSP MUST NOT be terminated even after its resources have been deallocated. 
Once the working LSP and the protecting LSP are configured or preconfigured, the end node MUST 
keep refreshing both working and protecting LSPs, regardless of failure or preemption status. 
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5.5. Availability of Shared Resources: The Notify Message 


When a lower-priority protecting LSP is preempted, the intermediate node that performed the 
preemption MUST send a Notify message with error code "Notify Error" (25) (see [RFC4872]) and 
error sub-code "Shared resources unavailable" (17) to the end nodes ofthat protecting LSP. Upon 
receipt ofthis Notify message, the end node MUST stop sending and selecting traffic to/from its 
protecting LSP and try switching the traffic to another protecting LSP, if available. 


When a protecting LSP occupies the shared resources and they become unavailable, the same 
Notify message MUST be generated by the intermediate node to all the end nodes of the protecting 
LSPs that have lower SMP preemption priorities than the one that has occupied the shared 
resources. If the shared resources become unavailable due to a failure in the shared resources, the 
same Notify message MUST be generated by the intermediate node to all the end nodes of the 
protecting LSPs that have been configured to use the shared resources. In the case of a failure of 
the working LSP, these end nodes MUST avoid trying to switch traffic to these protecting LSPs that 
have been configured to use the shared resources and try switching the traffic to other protecting 
LSPs, if available. 


When the shared resources become available, a Notify message with error code "Notify Error" 
(25) and error sub-code "Shared resources available" (18) MUST be generated by the intermediate 
node. The recipients of this Notify message are the end nodes of the lower-priority protecting LSPs 
that have been preempted and/or all the end nodes of the protecting LSPs that have lower SMP 
preemption priorities than the one that does not need the shared resources anymore. Upon 
receipt of this Notify message, the end node is allowed to reinitiate the protection switching 
operation as described in Section 4, if it still needs the protection resource. 


5.6. SMP APS Configuration 


SMP relies on APS protocol messages being exchanged between the nodes along the path to 
activate a protecting LSP. 


In order to allow the exchange of APS protocol messages, an APS channel has to be configured 
between adjacent nodes along the path of the protecting LSP. This is done by means other than 
GMPLS signaling, before any protecting LSP has been set up. Therefore, there are likely additional 
requirements for APS configuration that are outside the scope of this document. 


Depending on the APS protocol message format, the APS protocol may use different identifiers 
than GMPLS signaling to identify the protecting LSP. 


Since the APS protocol is left for further study per [G808.3], it can be assumed that the APS 
message format and identifiers are technology specific and/or vendor specific. Therefore, 
additional requirements for APS configuration are outside the scope of this document. 
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6. Updates to PROTECTION Object 


GMPLS extension requirements for SMP introduce several updates to the PROTECTION object (see 
[RFC4872]), as detailed below. 


6.1. New Protection Type 


Anew LSP Protection Type, "Shared Mesh Protection", is added in the PROTECTION object. This 
LSP Protection Type value is only applicable to bidirectional LSPs. 


LSP (Protection Type) Flags: 
0x20: Shared Mesh Protection 


The rules defined in Section 14.2 of [RFC4872] ensure that all the nodes along an SMP LSP are SMP 
aware. Therefore, there are no backward-compatibility issues. 


6.2. Updates to Definitions of Notification and Operational Bits 
The definitions of the N and O bits in Section 14.1 of [RFC4872] are replaced as follows: 


Notification (N): 1 bit 


When set to 1, this bit indicates that the control plane message exchange is only used for 
notification during protection switching. When set to 0 (default), it indicates that the control 
plane message exchanges are used for purposes of protection switching. The N bit is only 
applicable when the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 
0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional Protection), or 0x20 (Shared Mesh 
Protection). The N bit MUST be set to 0 in any other case. If 0x20 (SMP), the N bit MUST be set to 
1, 


Operational (O): 1 bit 


When set to 1, this bit indicates that the protecting LSP is carrying traffic after protection 
switching. The O bit is only applicable when (1) the P bit is set to 1 and (2) the LSP Protection 
Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 Unidirectional 
Protection), 0x10 (1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection). The O bit 
MUST be set to Oin any other case. 


6.3. Preemption Priority 


[RFC4872] reserved a 32-bit field in the PROTECTION object header. Subsequently, [RFC4873] 
allocated several bits from that field and left the remainder of the bits reserved. This specification 
further allocates the Preemption Priority field from the remaining formerly reserved bits. The 32- 
bit field in the PROTECTION object as defined in [RFC4872] and modified by [RFC4873] is updated 
by this document as follows: 
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(2 1 2 3 
CPE 7 ENCORE ER ST ES oO | esa ag 7 oh Cou 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
ITIR| Reserved | Seg.Flags | Reserved | Preempt Prio | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Preemption Priority (Preempt Prio): 8 bits 


This field indicates the SMP preemption priority of a protecting LSP, when the LSP Protection 
Type field indicates "Shared Mesh Protection". The SMP preemption priority value is 
configured at the end nodes of the protecting LSP by a network operator. A lower value has a 
higher priority. The decision regarding how many priority levels should be implemented in an 
SMP network is left to network operators. 


See [RFC4873] for the definitions of the other fields. 


7. IANA Considerations 


IANA maintains a group of registries called "Resource Reservation Protocol (RSVP) Parameters", 
which includes the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. IANA has 
added the following values to the "Sub-Codes - 25 Notify Error" subregistry, which lists error value 
sub-codes that may be used with error code 25. IANA has allocated the following error value sub- 
codes (Table 1) for use with this error code as described in this document. 


Value Description Reference 
17 Shared resources unavailable RFC 9270 
18 Shared resources available REC 9270 


Table 1: New Error Sub-Codes 


8. Security Considerations 


Since this document makes use of the exchange of RSVP messages that include a Notify message, 
the security threats discussed in [RFC4872] also apply to this document. 


Additionally, it may be possible to cause disruption to traffic on one protecting LSP by targeting a 
link used by the primary LSP of another, higher-priority LSP somewhere completely different in 
the network. For example, in Figure 1, assume that the preemption priority of LSP [A,E,FG,D] is 
higher than that of LSP [H,E,EG,K] and the protecting LSP [H,E,EG,K] is being used to transport 
traffic. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be disrupted. For this reason, it is 
important not only to use security mechanisms as discussed in [RFC4872] but also to 
acknowledge that detailed knowledge of a network's topology, including routes and priorities of 
LSPs, can help an attacker better target or improve the efficacy of an attack. 
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